Subject: Report to AIW on ATM Forum Activities

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Thu, 12 Sep 96 13:31:33 EDT

The AIW requested ATM Forum review and validation of AIW document ATM-06,
HPR Extensions for ATM Networks.  I attended the most recent meeting of
the ATM Forum Technical Committee in Baltimore August 19-23, 1996 to
answer questions and respond to comments.  This report contains the
comments received in Baltimore and the status on ATM Forum validation of
ATM-06.

I attended sessions of the Signalling working group (SIG), the
Multiprotocol over ATM working group (MPOA), and the Application
Programming Interface subworking group of the Service Aspects and
Applications working group (SAA-API).  Also, I informally asked the
chairs of the Network Management working group (NM) and the LAN
Emulation working group (LANE) for comments.  I have not yet received
any feedback from LANE.

MPOA
----

MPOA was primarily interested in HPR/ATM's use of multiprotocol
encapsulation.  (MPOA chair George Swallow indicated that HPR was
connection oriented and that MPOA's efforts to this point have been
targeted at connectionless protocols.  Further, he saw little
intersection between the HPR/ATM "overlay" model and MPOA.)  I
presented a few foils on HPR/ATM use of multiprotocol encapsulation.
Then, I asked specifically if a new layer 2 codepoint in BLLI was
needed for ISO 8802/2 using X'FE' SAPs (as defined in the extensions to
RFC 1483).  Joel Halpern (Newbridge) recommended that the standard
codepoint for ISO 8802/2 be used; he reasoned that the standard
codepoint was used for IP SVCs and for multiprotocol shared SVCs,
and that it would be a burden on implementations to define a new
codepoint for HPR.  I agreed with his rationale and indicated that I
accepted his recommendation

Regarding ATM-06's suggested use of BLLI negotiation to indicate the
first using protocol, Joel Halpern warned that, when the first BLLI IE
in SETUP was acceptable to the called endstation, the BLLI negotiation
protocol did not require the called endstation to examine the second
BLLI IE.  Thus, accepting a multiprotocol shared SVC does not
necessarily mean that the first using protocol is available.  Norm Finn
(Cisco) pointed out that techniques used to determine the ATM address
of the called endstation should guarantee that the called endstation
would support the first using protocol; he asked what value was gained
by indicating the first using protocol to the called endstation.  I
replied that the call could be rejected and tariff charges avoided if
the first using protocol was temporarily unavailable.  Norm agreed that
was a reasonable goal.

SIG
---

SIG was primarily interested in how HPR/ATM would exercise ATM signaling.
I gave a fairly thorough presentation of the HPR/ATM architecture.  I
also indicated that the AIW wished to get ATM Forum validation and that
we thought SIG should have primary responsibility for that validation.
The working group's response is discussed in the validation status below.

I received several comments (mostly from chair Tom Helstern and Robert
Dianda).  In my presentation, I noted that broadband bearer class C was
the default.  It was pointed out that use of class C might provide
unneeded services and result in higher than necessary tariff charges.
Consideration of class X as the default was recommended.  Note:
Subsequent review of RFC 1755, ATM Signaling Support for IP over ATM,
showed use of class X for best-effort UBR service and use of class C for
bandwidth-reserved VBR service.  As these appear to be reasonable
choices for HPR/ATM, I will make them the defaults.

Section 2.8 of ATM-06 lists typical QoS parameters needed by APPN
traffic.  As there is no guarantee that QoS class 3 would meet these
objectives, it was recommended that users study network service
offerings and specify QoS class accordingly.

ATM-06 used the terminology, "for both cell loss priority 0 and 1
traffic," when describing which peak cell rate parameter is used
for HPR/ATM.  This terminology was intended to clarify and have the
same meaning as the ATM Forum terminology "CLP=0+1".  It was felt that
the ATM-06 terminology was confusing and did not add clarity.  Note:
I will use the ATM Forum terminology but add a footnote to explain its
meaning.

When a called endstation receives CONNECT ACKNOWLEDGE, it may begin to
transmit data; however, the connection is not completed until the
CONNECT reaches the calling endstation.  As a result, there is a window
during which data may be lost.  I was asked if this would cause problems
for HPR/ATM.  I answered that XIDs were the first "data" traffic across
an SVC and that XIDs were sent reliably; thus, there is no problem.

I was asked why we required system definition based on the peak cell
rate supported by the remote adapter for regular defined links over
best-effort SVCs.  It was noted that the bottleneck could even be within
the ATM network and that to prevent cell loss, the endstation needed
a mechanism to slow down user traffic.  Such a mechanism could also
adjust for the capability of the remote adapter.  I answered that
I agreed that this system definition was not required and rather
should just be suggested.  Note:  It allows better settings for the
effective capacity TG characteristic for route selection and initial ARB
parameters determined via Route Setup.

Concern was voiced over the language in section 2.6 suggesting UNI 3.0
and UNI 3.1 would not interoperate with implementations of Q.2931, and
that there were no plans to converge ITU and ATM Forum signaling
standards.  I agreed to remove the offending language.  It was also noted
that Q.2931 only supports the unspecified QoS class 0.

Concern was also expressed about our default TG characteristics that
associated only cost per byte with best-effort VCCs and only cost per
connect time with bandwidth-reserved SVCs.  It was noted that carrier
ATM tariffs are hard to predict and that carriers have valid reasons
for cost-per-byte charges on bandwidth-reserved VCCs and
cost-per-connect-time charges on best-effort SVCs.  I noted that the
suggested TG characteristics were only defaults and could be overridden
by the customer when appropriate; I also agreed to make that point
more explicitly in the HPR/ATM document.

I indicated that the AIW would like the carriers to support BLLI
negotiation and thought it could be used to indicate the first using
protocol.  When the ATM network does not support BLLI negotiation, it
will remove the second BLLI IE from SETUP and not carry a BLLI IE in
CONNECT.  It was suggested that some carriers were expected to support
BLLI negotiation on a subscription basis.  It was also noted that the
calling endstation could determine that BLLI negotiation was supported by
the network if it received a BLLI IE in CONNECT provided that the called
endstation always sent a BLLI IE in CONNECT even if it only received one
BLLI IE in SETUP.  Note:  I haven't been able to find a use for this
technique.

I pointed out that the AIW would like to see dynamic modification
of bandwidth and QoS parameters in future UNIs.  The working group
received the comment but made no commitments.  I was warned this
function would often require a path switch within the ATM network.

SAA-API
-------

The primary interest of SAA-API was any requirements placed by HPR/ATM
on a native ATM API.  I gave essentially the same presentation that I
made for SIG.

Regarding BLLI negotiation, SAA-API agreed that if the first BLLI IE
was acceptable, the called endstation was not required by the BLLI
negotiation protocol to examine the second BLLI IE.  However, SAA-API
chair Jim Harford pointed out that in this case, an incoming call would
be passed to the entity above the API that had a "registration" matching
the first BLLI IE.  This entity, which could be a protocol multiplexing
function, would have access to the second BLLI IE and could reject the
call if the first-using protocol were unavailable.  If there were no
registration matching the first BLLI IE, the called would be passed to
an entity with a registration matching the second BLLI IE (if there were
one).

Jim Harford also pointed out that use of user-specified values in the
BLLI IE and RFC 1483 header could conflict with experimental programs.

There was additional discussion that system definition of peak cell rate
based on the remote adapter's capability is not required for best-effort
SVCs.  (See SIG discussion above.)

NM
--

NM chair Roger Kosak and other NM members looked at section 2.13.  Roger
reported to me that the section looked fine.

ATM Forum Validation Status
---------------------------

Prior to the Baltimore meeting Chuck Brotman and George Dobrowski (chair
of the ATM Forum Technical Committee) had agreed that I should come
to Baltimore to answer questions and respond to comments on ATM-06.
The plan was to ask George for a letter validating the document based
primarily on its review by SIG in Baltimore.  A contribution including
the entire ATM-06 document was submitted that requested ATM Forum
validation.

At the SIG meeting in Baltimore I indicated the AIW's desire for
ATM Forum validation of ATM-06.  However, SIG (and retiring SIG chair
Tom Helstern in particular) was reluctant to take on that assignment.
There were several reasons for their reluctance.  First, as I had
suspected, the members of the working group had not reviewed the
document prior to the meeting, and it was felt that a thorough review
was required for ATM Forum validation.  Second, the review in Baltimore
had resulted in several comments and concerns (see above), and the
working group wanted to see any resulting changes to the HPR/ATM
document.  Third, the working group feared an ongoing commitment to
review any document submitted to the ATM Forum by outside organizations.
A final problem was that SIG did not plan to meet at the October, 1996
ATM Forum Technical Committee meeting; the next SIG meeting is scheduled
for the December, 1996 ATM Forum Technical Committee meeting in
Vancouver.

I conferred with Chuck Brotman on the telephone.  We agreed that while
validation in September was preferable, validation in December was
acceptable provided that the ATM Forum could give us in September or
early October an informal indication that the HPR/ATM document was
acceptable or a list of problem areas that needed to be addressed.

I met with George Dobrowski and informed him of SIG's position and also
of my phone conversation with Chuck.  He indicated he wanted to
accommodate the AIW's request, and he agreed to meet with Tom Helstern to
see what could be worked out.  Later, George reported that he had met
with Tom and was looking for an expert to do the informal review we had
requested.

Since my return from Baltimore, Chuck has attempted to contact George
to confirm the plan for a December validation letter and to find out if
an expert has been chosen.  As of yet, he hasn't been able to talk to
George.  Meanwhile, I have worked the ATM Forum comments into the
HPR/ATM document, and an updated document (ATM-07) will be available
shortly.  We would like the expert to review the updated document.

Gary Dudley